This one is tricky, not so long ago we added a rule for JAVA and it caused a ton of breakage.

Yeah! This should only be merged after testing, of which I don't have any idea about. Though I think using IN_DIFF type is our safest bet here.

Or no rule at all.

Or no rule at all.

If some type of testing conducted fails, then yes, that's our only option.

But I would still recommend to not make any quick decisions, python having -12 nicesness isn't correct.

Thanks!

This one is tricky, not so long ago we added a rule for JAVA and it caused a ton of breakage.

Java is indeed a hard one, things like Minecraft have their own process name, but others like WAKFU that I was going to add on another PR has the default name "java" so I couldn't add it, python on the other hand would influence some programs like Proton VPN GTK on Arch or even plasmoids like panel colorizer (at the moment Panel Colorizer has -6 nice, their process name is just python3 and the file is service.py )

This is not good, if we really want to introduce compiler/python rules, then we need to disable ananicy-cpp out of the box again.

I know, for the general user expierence this could improve - but running Benchmarks on CachyOS will regress - massively.

This is not good, if we really want to introduce compiler/python rules, then we need to disable ananicy-cpp out of the box again.

I know, for the general user expierence this could improve - but running Benchmarks on CachyOS will regress - massively.

Makes sense as one of my compiler and linker adding PRs was rejected because of that.

I think a better way to handle these other rules like the python and compiler flags would be to add another repository named ananicy-rules-extra? And then create a submodule in the repo, one can recursively clone the repo if they want the compiler and other rules, otherwise just the normal rules.

This also allows making a separate package with the same repository name.